Robust and flexible digital rights management involving a tamper-resistant identity module

ABSTRACT

The invention relates to digital rights management, and proposes the implementation of a DRM agent ( 125 ) into a tamper-resistant identity module ( 120 ) adapted for engagement with a client system ( 100 ), such as a mobile phone or a computer system. The DRM agent ( 125 ) is generally implemented with functionality for enabling usage, such as rendering or execution of protected digital content provided to the client system from a content provider In general, the DRM agent ( 125 ) includes functionality for cryptographic processing of DRM metadata associated with the digital content to be rendered. In a particularly advantageous realization, the DRM agent is implemented as an application in the application environment of the identity module. The DRM application can be preprogrammed into the application environment, or securely downloaded from a trusted party associated with the identity module. The invention also relates to a distributed DRM module, with communication between distributed DRM agents ( 125, 135 ) based on usage-device specific key information.

TECHNICAL FIELD OF THE INVENTION

The present invention relates to digital rights management (DRM) formanaging digital content ordered and distributed over networks such asthe Internet.

BACKGROUND OF THE INVENTION

The distribution of digital content or media data using modern digitalcommunication technologies is constantly growing, increasingly replacingmore traditional distribution methods. In particular, there is anincreasing trend of downloading or streaming digital content from acontent provider to a user, which then typically renders or executes thecontent using a rendering or executing device according to some usagerights or rules specified in a license associated with the digitalcontent. Due to the advantages of this form of content distribution,including being inexpensive, fast and easy to perform, applications cannow be found for distribution of all types of media such as audio,video, images, electronic books and software.

However, with this new way of distributing digital media content comesthe need for protecting the content provider's digital assets againstunauthorized usage and illegal copying. Copyright holders and creatorsof digital content naturally have a strong economic interest ofprotecting their rights, and this has lead to an increasing demand fordigital rights management (DRM). DRM is generally a technology forprotecting the content provider's assets in a digital contentdistribution system, including protecting, monitoring and restrictingthe usage of the digital content as well as handling payment. A DRMsystem thus normally includes components for encryption, authentication,key management, usage rule management and charging.

The most basic threats to a DRM system include eavesdropping, illegalcopying, modification of usage rules, and repudiation of order, deliveryor usage of content. Most of these basic security problems are solved bystandard cryptographic techniques, including encryption, authenticationand key management. However, what basically distinguishes the securityproblems of a DRM system from other general security problems is thatnot even the other end-part of the communication (the end user) iscompletely trusted. In fact, the end-user might want to try tofraudulently extend his usage rights, for example rendering the mediacontent more times than he has paid for or illegally copying the digitalcontent to another rendering or executing device. Therefore, some formof rule-enforcement is required in the user's rendering or executingdevice. To this end, a tamper-resistant circuit and some formallanguage, such as XrML, expressing the usage rules are commonly usedtogether with the basic cryptographic techniques mentioned above.

Unfortunately, it now and then happens that the algorithms in thetamper-resistant DRM circuits are hacked, and a piece of software thatsuccessfully cracks some vital part of the DRM security of a particulartype of rendering device is openly distributed. From the viewpoint ofthe content provider, this makes all the rendering devices of this typeunsecure for DRM purposes, and the content provider may have to stopproviding digital content intended for these rendering devices, andinstead use another algorithm that has not yet been hacked. Recallingand replacing all the concerned rendering devices is obviously veryexpensive for the manufacturer/content provider.

A robust DRM system will make copyright holders more willing todistribute their material and offer a wider selection of content for endusers over open, untrusted channels such as the Internet. It will alsoprovide business opportunities for network operators to provide theinfrastructure for distribution, charging mechanism and so forth.

Another problem is that it is often difficult, sometimes evenimpossible, to move media content from one rendering or executing deviceto another. The media usage license is often associated with a singledevice, and if the user wants to use the content in another device, heneeds a new license. This is a cumbersome procedure for the end-user,and reduces the flexibility in the user's media system.

SUMMARY OF THE INVENTION

The present invention overcomes these and other drawbacks of the priorart arrangements.

It is a general object of the present invention to provide a robust andflexible DRM system.

It is another important object of the invention to provide tools for avery flexible and relatively secure client solution for digital rightsmanagement (DRM).

Yet another object of the invention is to provide a DRM mechanismallowing a network operator or corresponding party to be more active inestablishing and maintaining proper DRM functionality.

It is also an object of the invention to be able to reuse existinginfrastructure in designing a DRM system.

These and other objects are met by the invention as defined by theaccompanying patent claims.

A basic idea according to the invention is to implement a digital rightsmanagement (DRM) agent into a tamper-resistant identity module that isadapted for engagement, preferably physical engagement, with a clientsystem being capable of receiving and using digital content. The clientsystem typically has a network interface for receiving digital contentover a network, and a digital-content usage device such as a renderingdevice. The digital content is normally protected by the contentprovider, and transmitted in encoded form to the client, which needs todecode the protected digital content before usage of the content will bepossible. It may also be the case that the protected digital content isnot transmitted to the client system at all until charging has beenperformed or can be satisfactorily guaranteed. The DRM agent implementedin the tamper-resistant identity module generally includes functionalityfor enabling usage of ordered digital content, and without such a DRMagent, the client system will simply not be able to use the digitalcontent.

Hence, the DRM agent implemented in the tamper-resistant identity modulemay for example be provided with functionality for performing DRMprocessing to extract a proper content protection key and/or to enablecharging for usage of digital content.

The tamper-resistant identity module preferably comprises a module,perhaps even DRM internal, for performing at least relevant parts of anauthentication and key agreement (AKA) procedure, and the DRM agent inthe identity module may perform DRM processing based on information fromthe AKA procedure. For example, authentication information can be usedfor charging purposes, and key agreement information can be used forextracting a content protection key securely transferred to the clientsystem. The AKA procedure is generally performed based on one or moreidentity-module specific keys tamper-resistantly stored in the identitymodule. This could for example be a symmetric key shared between theidentity module and a network operator, a private key associated withthe identity module, and/or even a DRM specific key.

The identity module can be any tamper-resistant identity module known tothe art, including standard SIM cards used in GSM (Global System forMobile Communications) mobile telephones, UMTS (Universal MobileTelecommunications System) SIM (USIM), WAP (Wireless ApplicationProtocol) SIM, also known as WIM, ISIM (IP Multimedia Subsystem IdentityModule) and, more generally, UICC (Universal Integrated Circuit Card)modules. It is especially noted that the invention fits into the currentversion of the emerging OMA (Open Mobile Alliance) standard.

Although the invention is particularly suitable for mobile units andmobile DRM, the invention is not limited to network subscriber identitymodules used with mobile phones and communicators. For example, thetamper-resistant identity module may be a smart card associated with aset-top box for satellite TV or a tamper-resistant identity module for ageneral digital home entertainment center. The invention can in fact beused with any client, including conventional PC (Personal Computer)systems.

When using standardized SIM, USLM, VVIM, ISIM and UICC modules, the DRMagent may have a logical or physical interface to authentication andkeying algorithms pre-existing on the identity module, reusing thesubscriber-operator relation manifested by a subscription key. Thesubscriber-operator relation is typically also used for chargingpurposes in the overall DRM system.

It has been recognized that it is particularly advantageous to implementthe DRM agent as an application in an application environment providedin the tamper-resistant identity module, preferably the identity moduleapplication toolkit environment. The DRM agent application can bepreprogrammed into the toolkit application environment, or securely(preferably authenticated and encrypted) downloaded over a network froman external trusted party associated with the identity module. Theapplication toolkit environment is not the same as a true tamper proofencapsulated circuit, but it is far more secure than performing the DRMprocessing in an open, and perhaps even hostile PC environment, and moreflexible than using hard-wired tamper resistant circuits. For example,if a security flaw is found or if the whole DRM agent is hacked, thefunctionality is easily replaced or upgraded (even over the airinterface) by a new DRM agent. It should be understood that although asoftware agent is particularly beneficial, it is also possible to havethe DRM agent premanufactured as hardware in the identity module.

The proposed solution provides increased flexibility for the end-user aswell as the content provider and/or network operator. The identitymodule is easily replaceable (even remotely upgradeable), “portable”between different rendering or executing devices as well as relativelysecure.

For business models in which the usage of the digital content isrestricted, the DRM agent in the tamper-resistant identity module ispreferably configured for enabling only controlled usage of the ordereddigital content. For example, the DRM agent in the identity module mayinclude functionality for enforcement of usage rules associated with thedigital content.

Especially when the digital-content usage device is a stand-alone devicein the client system, the usage device is also provided with a DRMagent. In this case, it is recommendable to configure the DRM agent inthe identity module in such a way that it enables usage of the digitalcontent only by a usage device having a DRM agent that properly enforcesthe usage rules associated with the digital content. In this scenario,the overall DRM functionality of the client system is actuallydistributed, with a first DRM agent in the identity module and a secondDRM agent in the usage device. The communication between the two DRMagents is preferably based on usage-device specific key information. Inthis way, the communication between the two DRM agents can beauthenticated and/or protected. In the case of authenticatedcommunication, the main objective is to authenticate the usage device inorder to verify that the usage device has valid DRM functionality. Inthe case of protected communication, secure transfer of DRM metadatasuch as the content-protection key between the first DRM agent and thesecond DRM agent can be ensured.

The first DRM agent in the identity module is thus preferably providedwith functionality for enabling registration of digital-content usagedevices, storing usage-device specific key information for each usagedevice. The registration of usage devices is particularly important whenthe identity module is moved between different usage devices, or whenusing stand-alone digital-content usage equipment.

The invention gives a network operator or corresponding party thepossibility to be more active in establishing and maintaining proper DRMfunctionality on the client side, using the tamper-resistant identitymodule as a common point of trust. The identity module thus acts as acentral mediator of DRM associated data and/or functions. The operator,content provider and/or corresponding party is given the possibility tofully control the DRM functionality, in both the tamper-resistantidentity module and the interrelated usage device. In this respect, itis also beneficial to have the network operator (in processing a mediaorder) and/or a content provider (in processing a request for content)authenticate that the identity module used with the client systemincludes a compliant/valid DRM agent. In particular, the contentprovider may be interested in verifying that the usage device isassociated with compliant/valid DRM functionality. This can be achievedby relying on the operator/identity module authentication, implicitlyauthenticating the usage device.

The invention offers the following advantages:

-   -   From the end-user point of view, the invention provides flexible        and upgradeable implementation of DRM agents, as well as        “portability” between different rendering or executing devices.    -   A manufacturer of usage devices such as rendering devices        (players) can easily configure players to run with an external        DRM agent.    -   A network operator or corresponding party can efficiently manage        and upgrade DRM agents connected to the network, and the        invention also opens up new business possibilities for the        operator acting as a trusted center for content distribution.    -   A network operator or corresponding party is given the        possibility to be more active in establishing and maintaining        proper DRM functionality on the client side.    -   A DRM system built on the invention can reuse existing        infrastructure.    -   The DRM functionality on the client side is relatively secure,        while at the same time flexibly adaptable to upgrades.    -   Basing device registration on an identity module has the benefit        of allowing the establishment of a “home domain”, while making        it possible for a network operator to prevent different users        from forming a “global virtual domain”.

Other advantages offered by the present invention will be appreciatedupon reading of the below description of the embodiments of theinvention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further objects and advantages thereof,will be best understood by reference to the following description takentogether with the accompanying drawings, in which:

FIG. 1 is an overview of a digital rights management system for orderingdigital content over a network illustrating the relevant parties andtheir mutual relationships;

FIG. 2A schematically illustrates a client system according a preferredembodiment of the present invention;

FIG. 2B schematically illustrates a tamper-resistant identity moduleaccording a preferred embodiment of the present invention;

FIG. 3 is a flow diagram illustrating a digital rights management methodaccording to a preferred embodiment of the invention;

FIG. 4 is a schematic diagram illustrating an example of client-operatorauthentication and key agreement, client-side digital rights management,as well as the associated client-operator communication;

FIG. 5 illustrates a realization of the invention with DRM functionalitydistributed between a tamper-resistant identity module and an associatedrendering device according to an embodiment of the invention;

FIG. 6 illustrates an example of a distributed DRM module withcommunication between the distributed DRM agents based on a usage-devicespecific key according to a preferred embodiment of the invention;

FIG. 7A illustrates a challenge-response authentication procedurebetween the DRM agents in the DRM module of FIG. 6;

FIG. 7B illustrates encrypted communication between the distributed DRMagents in the DRM module of FIG. 6;

FIG. 8 illustrates a preferred implementation of a distributed DRMmodule with device-key based communication between a DRM agent in atamper-resistant identity module and a DRM agent in a rendering device;

FIG. 9 is a schematic flow diagram of a digital rights management methodfor establishing device-key based communication between distributed DRMagents;

FIG. 10 illustrates a tamper-resistant identity module and an associatedrendering device according to another embodiment of the invention;

FIG. 11 is a schematic diagram of an example of a DRM protocol involvingan operator, a tamper-resistant subscriber identity module, a contentprovider and a rendering device; and

FIG. 12 is a schematic block diagram of relevant parts of a DRM systemoperating based on the protocol of FIG. 11.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Throughout the drawings, the same reference characters will be used forcorresponding or similar elements.

The present invention is generally applicable to digital rightsmanagement (DRM) used in a digital content ordering and distributionsystem. In such ordering and distribution system, digital content ormedia is provided from a content provider to a client over a network,e.g. Internet and/or a wireless network for mobile communication,managed by a network operator. In order to facilitate understanding ofthe invention, a brief discussion of some general DRM functions follows.As was mentioned in the background section, DRM is used for protectingthe copyright holders' assets in a digital content ordering anddistribution system. In such a system, DRM typically regardsauthentication and key management usage rights management includingenforcement, and charging. These DRM functions are implemented in DRMmodules arranged in the relevant parties, i.e. for example in a clientsystem, in a server of the network operator and in a media or contentserver of the content provider.

Starting with authentication and key management, authentication is usedto identify the parties in the digital content ordering and distributionprocess. Techniques well known in the art, such as message, user and/ordevice authentication and digital signatures using cryptographic keys[1], may be employed for authentication. In addition, techniques formarking or stamping digital content, so that it can be tracked duringthe delivery process and subsequent usage, may be used. Watermarking andfingerprinting are two techniques that usually are employed for contentmarking. The DRM modules in the system also transport, store andgenerate, in a secure way, cryptographic keys for use in the digitalcontent ordering and distribution process. The keys are employed forcryptographically protecting messages, including the actual digitalcontent, during the delivery over the network.

The DRM modules also perform usage rule management, includingrule-enforcement. The ordered digital content is associated with alicense or digital permit specifying the client's usage rules and rightsof the obtained digital media. This form of management is about thedigital content itself and deals with issues such as, who gets it, howis it delivered, how may it be used, how many times may it be used(rendered, executed, saved, forwarded, copied and/or modified), how longdoes the rights last, who gets paid, how much they get paid and how.Some or all of these issues are specified in the license, which may bedelivered together with the digital content. In order to describe theusage rules, special languages called rights languages have beendeveloped. Two of the most prevalent rights languages used today areRights Markup Language (XrML) and Open Digital Rights Language (ODRL).In the client's rendering or executing device, the DRM module isimplemented to ensure that the usage, most often rendering, follows whatis described in the usage rules and to prevent repudiation of thedigital content and the usage rules.

Finally, charging management generally refers to the procedure of theactual payment for usage of the digital content. Several differenttechniques can be used, such as credit card techniques for payment overInternet, payment through a subscription or a pre-paid account, or evenby using “electronic cash”. A DRM system may also include management oftickets representing a value that can be redeemed and entitle the ticketowner access to specified digital content. The usage rights associatedwith ordered digital content is thus generally not limited to actual“usage” such as rendering, copying, forwarding and so on, but may alsoinclude redemption of the ticket value or parts thereof.

An example of a digital content ordering and distribution systemincorporating DRM functions is schematically depicted in FIG. 1, whichillustrates the relevant parties and their mutual relationships. Theexemplary system of FIG. 1 includes a client having access to a networkthrough an agreement, e.g. a subscription, with a network operator. Thisclient-operator trust relation is usually manifested in a cryptographicrelationship, i.e. sharing symmetric keys or having access to eachother's public keys (certified by a commonly trusted party) ifasymmetric cryptography is used. A trust relationship is also presentbetween the network operator and the content provider, but in the formof a business agreement. This agreement could be manifested by a similarkey sharing and/or key access as described for the client and networkoperator above. However, between the client and the content provider, aninduced trust relationship is established each time the client obtainsdigital content from the content provider. This induced trust ismanifested in a session key used for cryptographically protecting thedigital content as it is transmitted to the client over the network.

In a typical content ordering and distribution process, the client firstconnects to the network operator. The operator then authenticates theclient and possibly verifies that the client has a valid DRM agent formanaging DRM metadata, such as usage rules, encrypted data and keys,associated with the digital content. The client selects digital contentor media, and accepts/selects usage rules valid for the media, forexample allowing rendering the media a selected number of times orduring a given period of time. The basic usage rules are generallydetermined by the content provider, but some aspects of the usage rulesmay be open for user-selection. In the present description, digitalcontent refers to digital data that can be downloaded or streamed over anetwork for usage in a client system, and thus includes for exampleaudio, video, images, electronic books and other electronic textmaterial as well as software (application programs, computer games, andso forth). Other types of usage of the digital content than rendering orexecution includes forwarding, saving, copying, printing and possiblymodifying the digital content. In the following, the invention willmainly be described with reference to rendering of digital content. Itshould though be understood that the invention is not limited torendering of audio, video and text, but covers any usage or consumptionof media content, including execution of application programs andcomputer games.

An order is then placed to the operator, which writes andsecures/protects a ticket specifying the ordered content and the usagerules. The ticket is sent to the client, where the DRM agentauthenticates and decrypts the ticket and extracts a session key fromthe received ticket. The ticket can be decrypted by conventionalcryptographic means, e.g. using a symmetric key associated with theclient and the network operator or a private key of the client. Thisdecryption key is preferably the client-operator subscription key, aspecial DRM key associated with the DRM agent, or a key derived from oneor both of these keys. The extracted session key will eventually be usedfor decrypting the digital media from the content provider. The clientalso receives a copy of the ticket encrypted with the operator-contentprovider agreement key (or a key derived therefrom). This ticket copy isforwarded to the content provider, where the session key is extractedafter the validity of the ticket has been checked. Thereafter, thecontent provider delivers the ordered digital content cryptographicallyprotected by the session key to the client, either as downloaded data orstreaming data. Finally, the digital content is decrypted in the clientby the previously extracted session key. The digital content can now beused, e.g. rendered or executed, by the client or an associated deviceaccording to the usage rules. Further information regarding DRM systemsand ordering and distribution of digital content can be found in [2], aswell as in [3].

The overall content ordering and distribution process discussed above ismerely given as a simplified example for conveying a general image ofsuch processes. In order to increase the security, more authenticationand cryptographic steps may be introduced. In addition, the clientshould pay for the ordered content, so billing and charging steps aremost often present in the ordering process. Such a charging may beperformed by a subscription to the network operator, by sending theclient's credit card number to the network operator or to a dedicatedbilling institute managing the charging of digital content, or by someother means. In addition, the network operator may provide both networkservices and the digital content and may hence act as both operator andcontent provider at the same time. However, the operator then typicallyhas a dedicated content server and dedicated authentication/chargingserver(s), so that the parties illustrated in FIG. 1 are presentalthough the network operator also manages the content providingservices. In some applications, e.g. WAP (Wireless Application Protocol)applications, it is also possible that another client may act as acontent provider. The usage rules are then pushed to thecontent-receiving client from the network operator or the contentprovider.

It has been recognized that a partial solution to the objective problemsaddressed in the background section may be to use a portabletamper-resistant device that can be moved between rendering or executingdevices. However, if a user buys a new device, there is typically somecumbersome set-up procedure before the new device can be used.

The basic idea according to the invention is to implement a DRM agent ina tamper-resistant identity module that is intended for cooperation witha client system, such as a mobile phone or a computer system.Preferably, the tamper-resistant identity module is provided as a smartcard or equivalent, which is adapted for physical engagement withappropriate parts, such as a card slot, of the client system. The DRMagent is generally implemented with functionality for enabling usage,such as rendering or execution, of protected digital content provided tothe client from a content provider.

The usage is preferably controlled by usage rules associated with thedigital content. Typically, the DRM agent includes functionality forcryptographic processing of DRM metadata associated with the digitalcontent to be rendered. This metadata may for example be key(s) and userdata such as the encrypted digital content itself. For example, the DRMagent may include some basic functionality for more or less directlygenerating or extracting a decryption key to be used for decrypting theencrypted digital content. It is also possible to integrate the actualdecryption of the digital content into the DRM agent, as well asfunctionality for rule-enforcement and for enabling charging.

The identity module may be any tamper-resistant identity module known tothe art, including standard SIM cards used in GSM mobile telephones,UMTS SIM, WIM and ISIM modules, as well as general UICC modules.

In the following, the invention will mainly be described with referenceto a network subscriber identity module such as an SIM, USIM, WIM, ISIMor UICC module. Although the invention is particularly useful for mobileDRM based on a network subscriber identity module, it should beunderstood that the invention is not limited thereto. The identitymodule could alternatively be issued by a non-telecommunication actorand provided, for example, as a smart card issued by a bank to itscustomers, or as an identity module associated with a set-top box forsatellite TV or more generally for a digital home entertainment center.

By implementing the DRM agent in a network subscriber identity modulesuch as an SIM, USIM, WIM, ISIM or UICC module, the DRM agent ispotentially more secure than in an open and perhaps even hostile PCenvironment. This is because the operating system platforms of PCs, e.g.Windows and Linux, are more well known by the public than correspondingplatforms of SIM, USIM, WIM or ISIM modules, which thereby become harderto attack and modify. Due to the inherent tamper-resistance of suchnetwork subscriber identity modules, a proper security configurationwill be hard to override.

The fact that the subscriber identity module normally is removablyarranged in relation to the client system makes it easy to move theidentity module, with its DRM agent, between different devices, and alsofacilitates replacement of the DRM agent if it should be hacked.

Although the DRM agent may be implemented as special hardware in thenetwork subscriber identity module, the currently most preferredimplementation concerns a software-based DRM agent. It has beenrecognized that it is particularly advantageous to implement the DRMagent as an application in an application environment of the identitymodule, preferably the network subscriber identity module's applicationtoolkit environment, such as the GSM SIM Application Toolkit (SAT) orthe UMTS SAT (USAT) environment. The DRM agent application can bepreprogrammed into the application toolkit environment, or securely(preferably authenticated and encrypted) downloaded, or more generallyloaded, from a network operator associated with the subscriber identitymodule. The SAT, USAT or equivalent application toolkit provides anenvironment that can easily be upgraded with new software in a secureway, more of which will be described below.

In addition, the mobile operator's infrastructure can be used to solvethe set-up problems associated with using the DRM agent with newrendering devices, as will be explained later on.

FIG. 2A schematically illustrates a client system according a preferredembodiment of the present invention. The client may be any form ofappliance or system, which may order and obtain digital content over anetwork, for example a mobile phone with an identity module removablyarranged in a card slot, or a personal computer equipped with a cardreader into which such an identity module is inserted. In this exemplaryembodiment, the client system 100 comprises a network communication unit110, a tamper-resistant identity module 120 and a digital-content usagedevice, here illustrated as a rendering device 130. The networkcommunication unit 110 implements a network communication protocolstack, and thus enables downloading or streaming of digital content froma content provider to the client, using wireless or non-wireless networkcommunication.

As mentioned above, the tamper-resistant identity module 120 comprises aDRM agent 125 implemented in hardware, software or a combinationthereof. The rendering device 130 could also be implemented in software,hardware or a combination thereof. Preferably, the rendering device 130includes a media processor 131, which may be software-implemented, forrendering the digital content using e.g. a screen or a loudspeaker,depending on the type of digital content. The rendering device 130usually comprises some form of DRM functionality 135, for examplerule-enforcement and typically also decryption of the protected mediacontent based on a key generated by the DRM agent 125 implemented in theidentity module 120.

The rendering device may be integrated into a mobile unit or a PC, butcan also be provided as a stand-alone device directly (via suitablecommunication ports) or indirectly connected thereto. In the latterstand-alone case, the client may have one unit for downloading orstreaming of digital content and another physically separate unit foractually using or rendering the digital content, i.e. the renderingdevice. The downloading or streaming unit may e.g. be a personalcomputer or mobile unit with suitable hardware/software for receivingthe digital content. The content is then preferably transmitted to therendering device via ordinary cables or by wireless communication withor without involving a network. Typical stand-alone rendering devicesinclude Mp3 players, MD players, CD players, DVD players, other mobileunits or PCs. Alternatively, the rendering device has its own networkcommunication interface for receiving protected digital content andpossibly also usage rules associated therewith.

As mentioned above, the DRM agent may be implemented as a softwareapplication in the tamper-resistant identity module, as schematicallyillustrated in FIG. 2B. The identity module 120 preferably comprises aninput/output unit 121, an AKA (Authentication and Key Agreement) module122, a subscriber or subscription key k 123 as well as an applicationenvironment 124. The I/O unit 121 parses commands sent to the identitymodule and handles communication with the internal functions. The AKAmodule 122 comprises algorithms for mutual authentication between clientand network, and for deriving keys. This AKA function typically uses anidentity-module specific key, e.g. the subscription key k associatedwith the client-operator subscription, a key derived therefrom or a keyx associated with the DRM agent 125 implemented in the identity module.In GSM, for example, the AKA function is generally supported by theA3/A8 AKA algorithms. It is also possible to use asymmetric cryptographyfor authentication purposes.

In general, authentication and key agreement (AKA) procedures can bemore or less sophisticated, ranging from very simple AKA, with a keyagreement procedure where the secret key information is used directly asa session key, to more complex and secure AKA algorithms.

The application environment 124 is advantageously provided by theapplication toolkit of the identity module. For a GSM SIM, theapplication environment may be provided by the SIM Application Toolkit(SAT) [4], whereas the analogue application environment of UMTS SIM(USIM) is provided by UMTS SAT (USAT) [5].

For a GSM SIM, the SIM-ME (SIM-Mobile Equipment) interface as defined in[6] specifies the “commands” and data that can be sent to/from theSIM/ME. For instance, to run the GSM A3/A8 AKA algorithms, there is a“RUN_GSM_ALGORITHMS” command that routes input parameters/output resultsto/from the resident AKA algorithms. The AKA algorithms compute aresponse and/or one or more keys from a random challenge RAND and thestored subscriber key, k, or corresponding security key. In the list ofcommands possible over the SIM-ME interface, we specially note the“ENVELOPE” command, which is intended to send more or less arbitrarydata to the SIM for use with the SIM Application Toolkit (SAT). Theinput/output format to the SIM is explicitly specified, but there is ahigh degree of freedom exactly what the applications can do or not. Forinstance, the application could be a quite general Java Applet, see [7].The applet can be given various degrees of authorization to accessresident GSM-related files, one possibility being to give it “full GSMaccess”.

In a preferred embodiment of the invention, the DRM agent is implementedin the application environment provided by the SIM Application Toolkit(SAT) or a corresponding toolkit for another type of identity module,using the “ENVELOPE” command or an analogous command. Input data to theapplication is then preferably also transferred into the SAT by means ofthe ENVELOPE command. The SIM Application Toolkit (SAT) thus enables theoperator to “hardcode”, or download, over the air in the case of amobile, a DRM agent application into the SIM. In the latter downloadcase, it is also possible (and strongly recommended) to authenticate theDRM download application as coming from the right operator. This isimportant since it gives protection against downloading “viruses” frommalicious servers. The downloaded DRM application can also be encryptedso that the application content is not available outside the SIM. Forsecurity aspects related to GSM SAT, reference is made to [8]. Forcommunication between the DRM agent and the AKA module, there ispreferably, but not necessarily, a direct interface between the AKAmodule 122 and the SAT application environment 124. Execution of the DRMapplication in the SAT environment is naturally supported by theprocessing resources of the SIM. For more information on fundamentaldetails of the GSM SIM specification, reference is made to [9].

It should be understood that the application environment 124 mayoptionally be arranged with its own specific AKA module, operating basedon x and/or k.

Preferably, this AKA module is integrated in the DRM agent application,as schematically indicated in FIG. 2B.

By implementing the DRM agent of the tamper-resistant identity module inthe application environment, it is also possible to upgrade thefunctionality of the DRM agent. Upgrades are simply downloaded usingdownload commands associated with the client and implemented, e.g. usingthe ENVELOPE command, into the application environment of the client.This is an advantageous solution if the DRM agent is broken or “backed”,so that its code and/or secret keys become publicly available, e.g. onthe Internet. Then, instead of changing all client devices, theassociated DRM agent is simply updated by downloading and implementingnew algorithms and or keys.

For encryption and authentication in the DRM system, any standardcryptographic techniques may be used, including both symmetric andasymmetric encryption and authentication. Using symmetric encryptionand/or authentication, the encryption key is a shared symmetric key, acopy of which is stored both in the identity module and at the networkoperator or content provider. Alternatively, an asymmetric key pair maybe used for encryption and authentication based on a Public KeyInfrastructure (PKI). For asymmetric encryption, the public key is usedfor encryption and the corresponding private key for depcryption. Forasymmetric authentication, the private key is used for signing and thecorresponding public key for verification. Also, subscription-associatedusernames and passwords may be used in the context of authentication. Ifthe client has one or several network addresses, e.g. IP addresses,associated thereto, such address(es) can also be used forauthentication, at least to some extent.

In the following, however, encryption and authentication will mainly bedescribed in the context of symmetric cryptography, using the subscriberkey k and/or a DRM specific key x of the identity module. The DRMspecific key x, may be located anywhere in the identity module,preferably in the application environment, and even integrated in theDRM agent.

FIG. 3 is a flow diagram illustrating a digital rights management methodaccording to a preferred embodiment of the invention. The method isdirected towards the network operator side of the overall DRM system,and concerns the downloading, or more generally loading, of a DRM agentinto a tamper-resistant identity module arranged in relation to a clientsystem. As a recommended, but optional first step (S1) mutualauthentication is performed between client and operator or correspondingparty. The operator may optionally generate authentication data fortransmission to the identity module of the client to enable the clientto authenticate that the DRM agent comes from a trusted operator. Theoperator performs a download (S2), optionally authenticated, of a DRMagent into the identity module, for example as an SAT application intoan SIM using the “ENVELOPE” command. If required, for example due to asecurity flaw, the DRM agent may be remotely upgraded (S3) by thenetwork operator, which downloads the required patches or entirely newDRM algorithms. The operator or content provider may also authenticatethat requesting clients have identity modules with compliant DRM agents,using any known authentication technique. This authentication of the DRMagent normally includes verification that the DRM agent is of acompliant type, but preferably also includes DRM agent versionverification.

FIG. 4 is a schematic diagram illustrating an example of client-operatorauthentication and key agreement, client-side digital rights management,as well as the associated client-operator communication. In thisparticular example, the client sends a request for authentication (orDRM activation), together with an identification tag, to the operator.The operator performs authentication and key agreement (AKA) using arandom challenge, RAND, other optional user data, the key k and/or aspecial DRM key x as input to cryptographic functions f and g, thusgenerating a session key t to be used for secure communication betweenthe client and the operator and an expected response, XRES,respectively. The operator sends the random challenge, RAND, possiblytogether with an authentication tag, to the identity module of theclient. The data is received by the client's identity module and, if anauthentication tag is present, the identity module first authenticatesthe received data using k/x and then runs the same AKA functions f and gwith the same input to derive the session key t and a response, RES. Theresponse, RES, is sent back to the operator and compared to thepreviously calculated expected response, XRES, so that it can beverified that the operator is in contact with the right application. Inthe following, E_(z)(m) represents a message m, protected by a key z.“E” is intended to denote “encryption”, but it may (and often should)also encompass authentication, integrity and, for certain types ofdigital content, perhaps even replay protection. Next, the client placesan order, protected by the session key t, to the operator. The operator,which in this particular example acts as an order server, generates aticket and a further session key s, also referred to as a media orcontent protection key, and encrypts the ticket and the key s with thepreviously generated session key t. The encrypted ticket and mediaprotection key s is sent to the client, which invokes the DRM agent inorder to decrypt the ticket and the media protection key s by using thekey t. The media protection key s and the associated ticket are alsosecurely forwarded to the content provider, which then encrypts theordered digital content by using the media protection key s and sendsthe protected media to the client. Once received by the client, theprotected media content is decrypted, either by the DRM agent or morelikely by some DRM functionality present in the rendering device, usingthe media protection key s.

The identity module is preferably the base for a charging mechanism thatcan be used also for payment of digital content in the DRM system. Inthe simplest form, charging for digital content usage issubscription-based, and the AKA procedure in the identity module ensuresthat the correct user/subscriber will be charged and billed for thecontent. The same applies to a pre-paid subscription where it isrequired to make sure that the correct pre-paid account will be accessedfor charging. In a more advanced solution, credit cards or some form ofmicropayments may be used, where information, such as a session key,from the AKA procedure can be used to protect transfer of charging datasuch as credit card number or payment “ticks”, possibly together withintegrity protected information concerning the usage of the content.

It is for example possible to configure the DRM agent in the identitymodule, especially when it is closely associated to the renderingdevice, in such a way that it compiles information related to the actualdigital-content usage process, such as information concerning whatcontent that was used, the quality of the used content, what amount ofdata and for how long or how many times the content was used. Thisinformation may then serve as a basis for charging for digital-contentusage. The compiled information may then be integrity protected based onan identity-module specific key k/x and transferred to the networkoperator or to a dedicated billing institute managing the actualcharging of digital content.

As previously indicated, the DRM agent implemented in the identitymodule typically includes functionality for cryptographic processing ofDRM metadata associated with the digital content to be rendered. Thismetadata may for example be one or several keys as well as encryptedinformation. Normally, the DRM agent includes some basic functionalityfor more or less directly generating or extracting a decryption key tobe used for decrypting the encrypted digital content, as described belowwith reference to FIG. 5.

In FIG. 5, the identity module and the rendering device are shown asseparate units. These units can be co-located in the same client device,such as a mobile telephone, PC, radio receiving unit, or alternatively,the rendering device can be provided as an external stand-alone clientdevice whereby the separate client devices are interconnected directlyor indirectly. The block diagram of FIG. 5 only illustrates thosecomponents that are relevant to the invention. The identity module 120has an AKA module 122, and a DRM agent 125. Among other things, the AKAmodule 122 generates the session key t, preferably based on thesubscriber key, k, and/or a special DRM key, x. The DRM agent 125comprises a cryptographic unit C1 for extracting the media protectionkey (also referred to as a session key) s based on the session key treceived from the AKA module 122 and the encrypted information E, (s)received from the network operator. In this embodiment, the renderingdevice 130 includes a media processor 131 and a DRM agent 135. The DRMagent 135 in the rendering device 130 includes a cryptographic unit C2for decrypting the protected media content from the content provider byusing the media protection key extracted by the DRM agent 125 in theidentity module. The decrypted media content is finally sent to themedia processor 131 in the rendering device 130 for preparing the actualrendering.

It should be noted that the protection of the content protection key s,for example as shown in FIG. 5, is preferably applied at the applicationlevel, thus facilitating functionality upgrades. In a typicalcommunication system (e.g. GSM, UMTS), the content protection key s willalso be protected at a lower (link) layer by the (air) interfaceprotection. This latter protection is naturally also based onkey-agreement procedures, typically using only the network subscriptionkey k. In other words, the content protection key will typically be“double” protected, at the link layer by a key t′(k) and at theapplication level by the key t(k/x). If one has enough confidence in thelink layer protection and the tamper-resistance of the client system,further protection by t at the application level may be omitted.

Throughout the following examples, it should be understood that whenapplication level protection is applied, there mayoptionally/alternatively be a DRM-internal AKA module (indicated bydashed lines), preferably operating based on a DRM-specific key x.

For a distributed DRM module, with a first DRM agent in the identitymodule and a second DRM agent in the usage device, it might beadvisable, especially when the usage device is a stand-alone device, totamper-resistantly configure the identity module and the usage devicewith usage-device specific key information for allowing communicationbetween the two DRM agents based on this device key information.

The device key information may be a shared secret key, or an asymmetrickey pair, allowing authentication and/or protection of informationcommunicated between the DRM agents. The device key is normallytamper-resistantly stored in the rendering device, and theinfrastructure of the network operator and/or a trusted certificationparty can be used for securely transferring corresponding device keyinformation for storage in the tamper-resistant identity module, as willbe described later with reference to FIG. 9.

FIG. 6 illustrates an example of a distributed DRM module withcommunication between the distributed DRM agents based on a usage-devicespecific key according to a preferred embodiment of the invention. Insimilarity to the basic structure of FIG. 5, the identity module 120comprises an AKA module 122 and a first DRM agent 125, and the usagedevice, here illustrated as a rendering device 130, comprises a mediaprocessor 131 and a second DRM agent 135. The DRM agents 125, 135 may beimplemented in hardware, software or a combination thereof.

In the particular example of FIG. 6, which relates to symmetricauthentication and/or encryption, both the identity module 120 and therendering device 130 are configured with a shared secretrendering-device (or more generally usage-device) specific key, y. In anexemplary embodiment, the shared device key y is implemented in the DRMagents 125, 135 of the involved entities. This is a perfectly validsolution, for example when the DRM agent 135 of the rendering device isimplemented as a hardware circuit. However, it may be beneficial totamper-resistantly implement the device key, y, outside of the DRM agentin the rendering device, especially when the rendering device DRM agentis a software-based application. In this case, the device key y ispreferably stored in the rendering device within a specialtamper-resistant environment, such as a dedicated security circuit (asindicated by the dashed box containing “y” in FIG. 6).

The communication channel between the two DRM agents is preferablyauthenticated and/or protected based on the device key, y, or possibly adevice key representation. In the case of authenticated communication,as illustrated in FIG. 7A, the DRM agent in the identity module canauthenticate that it is in contact with a usage device having a valid,tamper-resistant DRM agent. More particularly, the first DRM agent 125authenticates the usage device to verify that it includes a valid DRMagent 135, for example one that properly enforces the usage rulesassociated with the content. Preferably, an explicit authentication isperformed using a challenge-response procedure based on the device key,y. The communication between the distributed DRM agents mayalternatively, or as a complement, be encrypted or otherwise protected,as illustrated in FIG. 7B. The DRM agent 125 in the identity module 120could then rely on implicit authentication, i.e. only a rendering device130 implementing the key, y, can decrypt DRM data encrypted by thedevice key, y. Although the device-key based communication is especiallyuseful when the rendering device is a “stand-alone” device, it should beunderstood that device-key communication is also applicable for a clientdevice, such as a mobile phone, having its own integrated renderingapplication, thus pairing the identity module to the mobile phoneitself.

The device-key based communication between the tamper-resistant identitymodule and the rendering device may be used for transferring DRM data,such as content-protection keys, information concerning thecontent-usage process, and even DRM applications/upgrades between thetwo entities, as will be exemplified below.

If the rendering device is a stand-alone device, it is recommended thatit has its own DRM rule-enforcement and that the usage rules are sent inthe ticket along with the media, or forwarded from the identity module'sDRM agent, so that the rendering device can act as an agent on behalf ofthe content owner/provider and assert that the usage rules are followed.

FIG. 8 illustrates a preferred implementation of a distributed DRMmodule with device-key based communication between a DRM agent in atamper-resistant identity module and a DRM agent in a rendering device.More specifically, the implementation of FIG. 8 illustrates how a mediaor content protection key s can be sent encrypted between the DRM agentof the identity module and the DRM agent of the rendering device, with ahigher level of security for the actual device key. Although it ispossible to implement the identity module with an instance of the devicekey y, and encrypt the content protection key s directly by the devicekey y itself, it is normally recommendable to determine another key y′derived from the original device key y and securely transfer thedetermined key y′ to the identity module for use in providingsecure/authenticated communication between the distributed DRM agents.In this way, there is no need to store the actual device key y in theidentity module.

With reference to FIG. 8, the DRM agent 125 in the identity module 120comprises two logically separated cryptographic units C1 and C3. Thecryptographic unit C1 is similar to that of FIG. 5, and thecryptographic unit C3 is configured to encrypt the protection key s bymeans of the key y′, before transmittal to the rendering device 130. Itis here assumed that the device key representation y′ has beenimplemented in the identity module, and more particularly in the DRMagent 125. The key y′ may for example be derived by a trustedcertification party, using the secret device key y (or a representationthereof) and a challenge r as input to a cryptographic function C′, andthen securely transferred for storage in the identity module, as will beexplained in more detail later on.

In order to be able to perform “device-key” based communication betweenthe two DRM agents, the rendering device must be capable of determiningthe device key information y′. To this end, the rendering device 130 ispreferably equipped with a tamper-resistant security circuit 133, whichincludes both the device key y and a cryptographic function C″(corresponding to the function C′), which in response to the challenge rand the internal device key y determines y′. In this way, the device keyy never have to leave the controlled environment of the tamper-resistantsecurity circuit, and a high level of device key security is maintainedeven with a software-based DRM agent in the rendering device.

The challenge, r, is preferably transferred from the trustedcertification party to the identity module, perhaps at the time when y′is transferred to and implemented in the identity module, or later, e.g.when the encrypted content and/or a corresponding ticket is transferredto the identity module. The challenge r may optionally be stored in theidentity module. Subsequently, the challenge r is transmitted, possiblyalong with the encrypted content protection key, s, to the second DRMagent 135 in the rendering device 130. The DRM agent 135 in therendering device 130 invokes the security circuit 133 by forwarding thechallenge r, and the security circuit responds by forwarding the devicekey representation y′ to the DRM agent 135. The DRM agent 135 in therendering device 130 also includes a cryptographic unit C4 fordecrypting the encrypted key s by using the generated key y′, and acryptographic unit C2 for decrypting the encrypted media content byusing the decrypted key s. The digital content is finally the sent tothe media processor 131 for rendering. The key y′ can be regarded as asession key that is unique for each communication session between theDRM agent in the identity module and the DRM agent in the renderingdevice. Of course, an explicit challenge-response authenticationprotocol based on the device key, y, or the device key representation y′can also be implemented in the distributed DRM module of FIG. 8.

FIG. 9 is a schematic flow diagram of a digital rights management methodfor establishing device-key based communication between distributed DRMagents. The rendering device is tamper-resistantly configured with ausage-device specific key y (S10).

As the device key y is specific to the rendering device, the client (theidentity module) may establish a trust relation with that device, inparticular the very first time when the rendering device is brand new.Note that it is not secure to simply write “y” on the outside of therendering device, as it could be copied and a cloned, non-secure devicecould easily be created. Instead, identification information, such asthe result of applying some cryptographic function h to the key y may beattached to a “label” on the rendering device when it is sold, ortransferred from the rendering device to the associated client devicewhen interconnected, thus making a cryptographic representation of thedevice key available to a user/the client device (S11). Thecryptographic representation of the device key may, for example, involvea one-way cryptographic function, symmetric or asymmetric encryption.The device is associated with a random, secret device key y, and whenthe buyer wishes to activate the device, he sends the (open)cryptographic representation h(y), or similar identificationinformation, to the operator (or another trusted certification party)who checks that h(y) is assigned to a valid device, retrieves the devicekey (S12) or suitable key information, such as y′, derived from thedevice key, and finally updates (S13) the DRM application in theidentity module with the device key y or key information derivedtherefrom.

It is assumed that the operator or another trusted certification party(in some business models, the trusted party may be the devicemanufacturer) has some key that enables him to invert the function h orotherwise is capable of retrieving suitable device key information, e.g.by using look-up tables (S12). For example, it may be the case that thedevice key itself should never be available outside of the renderingdevice, not even explicitly known by the certification party. In thiscase, the certification party is capable of retrieving key information,such as y′, that is based on the actual device key y and perhapsadditional input data.

It is also assumed that the device key information is securelytransferred from the certification party to the identity module in theclient device based on some identity-module specific key (S13). Onceproperly configured in the DRM agent of the identity module, the devicekey information, i.e. the device key or some other key derived from thedevice key, may be used for establishing communication (secure and/orauthenticated) with the DRM agent in the rendering device (S14).Apparently, if a key derived from the actual device key y is transferredto and implemented in the identity module, the rendering device has toimplement some function that based on the device key generates the samekey derivative as in the identity module.

The value y can be checked by the certification party to verify thatonly “authentic” (i.e. not stolen, hacked or otherwise compromised)rendering devices, ones with “valid” y-values, are used in the system.If a user purchases a new rendering device, he can add support (a newkey in his identity module) for the device in a simple way. This can beused for registration; in the identity module (as well as in a thirdregistration party), of various rendering devices with which the client(identity module) wants to establish trust relations.

In DRM, there is often a requirement of “fair use”, i.e. if a user buyscontent, he or she should be allowed to use it on any (DRM compliant)device successfully registered in his “home domain” (e.g. a familydomain). However, there is a risk that different users across the worldform a “global virtual domain” so that content can be shared more orless globally anyway. The present invention can limit the risk of suchglobal spreading of content. Since the device registration is based onan identity module, tied to a user or subscription, it is possible forthe trusted party (e.g. the operator) that manages registration requeststo verify that a new device is allowed in a certain domain. Forinstance, if three family members have subscriptions with the sameoperator (or different operators under contractual agreement), theoperator can verify that if a device has already been registered, it wasby a user belonging to the same domain. Following a successfulregistration, the operator authorizes the device to be registered in thenew identity module, e.g. by sending device specific keys or otherinformation.

It should be understood that the response of sending the “labeled”identification key to the certification party may be any a device keyrepresentation allowing the DRM agent to communicate with the DRM agentof the rendering device.

The actual key information used for communication between thedistributed DRM agents may be the same independent of what identitymodule that is used. Alternatively, however, the key information usedfor authenticated and/or secure communication is made dependent on theusage device key as well as on the particular identity module that iscurrently associated with the rendering device. In this way, differentclient terminals (each having its own identity module) associated withthe same rendering device may have unique device key information.

This actually represents a special case of sending a key derived fromthe device key y, rather than sending the device key itself, from thetrusted certification party to the identity module. As before, thecryptographic representation h(y) of the device key y is sent to theoperator (or another trusted certification party) who checks that h(y)is assigned to a valid device. The operator then, for example, generatesa value b that depends on an identity-module specific key, such as kand/or x, and finally generates a device key representation y″ based onthe generated value b and the device key y:b=function (k/x),y″=function (b, y).

Preferably, the values b and y″ are securely transferred from theoperator to the identity module. The device key representation y″ (andpossibly also b) is securely stored in the identity module, and thevalue b is transferred to the rendering device (possibly together withan identity module identification). The rendering device, which isconfigured with an instance of the same function for generating thedevice key representation y″ as the operator, calculates y″ based on band the internal device key y. The key device representation y″ may thenbe used for communication between the identity module and the renderingdevice, in analogy with the embodiment of FIG. 8.

If a strict dependence on k/x is not desired, the value b could simplybe a random number or other value generated or assigned by the operator,or corresponding party.

It should also be understood that the device key in the rendering devicecould alternatively be a private key, with the identity module holding acopy of the corresponding public key.

As previously described, the DRM agent in the identity module may beconfigured to compile information about the digital-content usageprocess that can be used as a basis for charging. However, for adistributed DRM module with a first DRM agent in the identity module anda second separate DRM agent in the actual rendering device, this usageinformation is typically compiled by the DRM agent of the renderingdevice. The second DRM agent compiles the information as the renderingdevice consumes the digital content, and sends the information to thefirst DRM agent, preferably using the authenticated and/or securedevice-key based communication. For example, it is beneficial to use thedevice key to integrity protect the compiled information. The first DRMagent authenticates and/or decrypts the compiled information based oncorresponding device key information and stores the information in a logand/or sends the information to an external trusted party for logging.Preferably, the first DRM agent integrity protects and/or encrypts thelog information before transferring it to the external trusted party,using symmetric or asymmetric cryptography. This logging information canthen be used, e.g. for non-repudiation purposes.

In a more elaborate communication protocol, the first DRM agent and thesecond DRM agent exchange control signals for controlling the renderingprocess, or more generally the usage process. For example, the secondDRM agent in the rendering device intermittently generates anacknowledgement ACK signal indicating that the process of using receiveddigital content proceeds without disturbances. The ACK signal ispreferably accompanied by log information, e.g. related to the amount ofrendering time, amount of successfully rendered data, rendering quality,time delays, buffer overflows, and other data concerning the renderingprocess. The first DRM agent includes functionality for processing thissignal information and for sending a so-called forward proceed signalFPS to the second DRM agent in response thereto. The FPS signal isrequired in order for the rendering process to continue, whereas amissing FPS signal causes the rendering process to stop or to proceedaccording to predetermined limitations, e.g. limited Quality of Service(QoS). The FPS signal may include information, such as a Device AccessCode (DAC) extracted from the corresponding ticket by the first DRMagent or information obtained by analyzing the log data received fromthe second DRM agent, that can be used for controlling the renderingprocess. The second DRM agent is thus configured for receiving the FPSsignal and for controlling the rendering process in dependence on dataassociated with the FPS signal. This type of communication protocol maybe particularly useful in so-called broadcast applications, where thelogging information from the second DRM agent serves as a basis forcharging. If the first DRM agent does not receive such logginginformation, the first DRM agent is capable of controlling the continuedrendering process by means of the FPS signal.

The first DRM agent may also be capable of extracting the usage rulesassociated with the digital content from the ticket and forward theserules to the rendering device for enforcement by the second DRM agent.Alternatively, however, the usage rules are sent directly, preferablytogether with the encrypted digital content, to the rendering device andthe DRM agent therein.

This communication protocol preferably utilizes the device-key basedcommunication described above, in which authentication and/or encryptionbased on usage-device specific key information is performed.

In similarity to a DRM agent implemented as an application in anapplication environment within the identity module, the DRM agent in therendering device may also be implemented as a software application,preferably in a tamper-resistant application environment in therendering device. This means that a DRM application adapted for use in arendering device may be downloaded into the rendering device applicationenvironment either via a network operator and the associated identitymodule (with its DRM agent), or more or less directly from a contentprovider or corresponding party, based on usage-device specific keyinformation.

It should be noted that “download” of DRM agents is possible also when adevice does not have its own means for outbound communication. Considerfor instance a TV receiver and a set-top box. To upgrade the TV and/orset-top box with new DRM functionality, one can proceed as follows.Using a separate communication device, e.g. a telephone, the user ordersa DRM agent. If needed, device specific data is entered that enables theoperator to configure the DRM agent to the device, e.g. encrypting itwith device specific keys. The DRM agent is then transported to thedevice by allocating bandwidth on the broadcast channel. For instance,in the case of a TV receiver, the DRM agent could be transported byencoding it into the Text-TV information channel. For radio, the RDSinformation channel might be used. If the DRM agent is encrypted withdevice specific keys, it does not matter that the broadcast medium iseasily intercepted.

To ensure proper authentication of the DRM agent in the rendering devicewhen a DRM agent or a new upgraded version of such a DRM agent isdownloaded, the original (current) device key information shouldpreferably be replaced by new device key information that is associatedwith the downloaded DRM agent. This typically implies that the devicekey information is stored in a rewriteable memory, for example in atamper-resistant security circuit provided with a rewriteable memory, ina tamper-resistant rendering device application environment or a memoryaccessible from such an application environment.

Preferably, the DRM agent and a re-initialization value associatedtherewith are securely (encrypted and/or authenticated) downloaded intothe rendering device application environment based on the original(current) device key. The original device key, here denoted y₁, togetherwith the re-initialization value re-init, preferably authenticated basedon the original device key, are used as input to a cryptographicfunction, f′, to generate a new device key, denoted y₂, which thenreplaces the original device key y₁ in the rewriteable memory:y ₂ =f′(y ₁, re-init).

For example, the re-initialization value re-init may be generated by anetwork operator, a content provider or trusted certification party,which party uses the same function f′ and the same input y₁ and re-initto generate the new device key y₂. If the DRM agent and there-initialization value re-init are transferred to the rendering devicevia a network operator and the associated identity module, and the DRMagent in the identity module is configured with a copy of the functionf′ and the original device key y₁, the new device key y₂ may begenerated directly in the identity module, replacing the original devicekey information. Alternatively, as previously described for the originaldevice key, the new device key or a representation thereof may besecurely transferred from the certification party to the identity modulebased on an identity-module specific key, such as a subscription key k.

The new device key information can then be used, for example forcommunication between distributed DRM agents in the client system, orwhen later downloading an even newer DRM agent into the rendering deviceapplication environment.

In general, there may be other circumstances that call for replacementof the device key, for example if the device key y is compromised. Thedevice manufacturer or some other trusted party may have access to aDevice Access Code (DAC), which when applied to the device enables(authenticated) replacement of the device key. It should though beunderstood that replacement of the device key in the rendering devicedoes not generally form part of the normal everyday routines for digitalrights management, and that device key replacement typically alsoimplies administrative procedures such as updating devicekey/identification databases.

If the rendering device is to be transferred to another user having itsown client terminal such as a mobile or PC, the previously described“registration procedure” for transferring corresponding device keyinformation into the identity module in the new client terminal isnormally performed. As mentioned, it is usually better to register keyinformation derived from the device key rather than the device keyitself so that the device key, y, will not be present in each and everyclient terminal used with the rendering device. Anyway, it may beadvantageous to revoke or otherwise invalidate the device keyinformation in user terminals that no longer should be used with thatrendering device. There are several different ways of dealing with thisproblem. For example, the device key, y, in the rendering device may beupgraded, so that “old” terminals cannot be used with the deviceanymore. This could be done by an authorized service point, or remotelyover a network. Alternatively, the device key information in theidentity module may deleted by a trusted party such as a networkoperator, for example through the use of an identity-module specificaccess code allowing deletion of the device key and/or by authenticatingthat the “delete” command comes from the trusted party.

On the other hand, as previously mentioned, there could also be caseswhen it is actually desired that the same device can be used by two (ormore) different user terminals/identity modules.

It is also recognized that the use of “keys” inside devices could beused for anti-theft purposes: without knowing the key, the device isuseless, and if someone tries to configure a device, it could be checkedagainst a register of stolen devices.

In a more open application environment, the tamper-resistance of therendering device and its DRM functionality may be provided based on theconcept of security-by-obscurity, writing the software code andassociated keys in a complicated, obscure manner in order to make itextremely difficult for an external party to understand the code andeven more difficult to distinguish security keys from the remainingcode.

In addition to the security aspects discussed above, it is normallyrequired to perform the actual decryption of the digital content in theDRM agent of the rendering device because of the limited processingcapacity of standard identity modules of today. However, with increasedprocessing capacity in the identity modules, for example in futuregeneration identity modules such-as future UICC cards, it may befeasible to integrate the decryption of the content into the identitymodule's DRM agent, as illustrated in FIG. 10. This realization,however, typically relates to the case of a client device, such as amobile unit, having its own integrated rendering application, withsomewhat more relaxed security requirements with regard to digitalrights management. In the example of FIG. 10, the identity module 120comprises both a cryptographic unit C1 for generating the mediaprotection key s, and a cryptographic unit C2 for decrypting theencrypted media content using the protection key s from thecryptographic unit C1. The decrypted media content is then sent to therendering device 130 for processing and rendering. If rule enforcementis required, such rule enforcement functionality may also be implementedin the DRM agent of the identity module. It is thus apparent that adistributed DRM functionality is not always required by the invention.

For a more complete understanding of the invention, an exemplary DRMsolution will now be described with reference to FIGS. 11 and 12, whichschematically illustrate the overall DRM protocol and a correspondingclient side block diagram, respectively.

As mentioned, in a DRM solution, part of the DRM processing normallymust take place in a tamper resistant device, preferably atamper-resistant identity module. For a more detailed understanding ofthe invention, the example of FIGS. 11 and 12 will refer to a networksubscriber identity module such as a GSM SIM, USIM, WIM, ISIM card,hereinafter simply referred to as an SIM. Typically, a container isdownloaded that comprises key(s) and/or data, and this key(s)/data needto be processed in a protected environment. Here, the processingbehavior could be entirely specified by a SAT/USAT or correspondingapplication, possibly interfacing with the authentication/key generationalgorithms preexisting on the card, reusing the operator-subscriberrelation. Using SAT in this context is not the same as using a “true”tamper resistant module, but it is more secure than performing theprocessing in an open and perhaps even hostile PC environment and moreflexible than using hard-wired tamper resistant modules. If a securityflaw is found, the card is easily upgraded (even over the air) by a newset of DRM processing algorithms.

In this example, it is assumed that the SIM card 120 (FIG. 12) containsk, the usual subscriber key. The SIM also contains an applicationenvironment (e.g. SAT/USAT) that is premanufactured with a DRMapplication, or alternatively, the DRM application is securely(encrypted and authenticated) downloaded. Also, a second key, x,specific for DRM purposes is present in the SIM and at the operator.Like k, also x is stored so that it cannot be read out of the SIM card.Note though that x may be stored in software, e.g. as part of the DRMapplication, if enough protection can be guaranteed. Besides the networkoperator, there is a content provider, which, if distinct from theoperator, has a contractual agreement with the operator, manifested by ashared key c.

First, and optionally, each time the DRM agent in the SIM is to beinvoked, the application verifies that it is running in a trustedenvironment, e.g. by a mutual authentication protocol. This protocolcould be based on knowledge of the key x, or some other informationshared between the SIM and the rendering device with which the SIM isrelated, e.g. another key y. This might be desirable in cases where thewhole SIM can be moved between devices, in which case there is oneunique key, y, for each device the SIM is used with.

When the user has decided what media he wants (and possibly paid for it,if payment is not done afterwards or during the session), he notifiesthe network operator that he wishes to use the DRM application, and theoperator performs authentication and key-agreement using a randomchallenge rand, other optional user data, the key x and optionally alsothe key k. This authentication could optionally have been done before,e.g. when gaining network access. The key k is used when it is necessaryor appropriate to tie the key generation to the subscription as such.This AKA is done using some cryptographic functions f and g, which, incase we desire dependence also on k, may partially consist of the normalSIM authentication algorithm.

In other words, the operator sends rand (and optional [user_data], ifnot already known by the DRM application on the SIM) to the SIM (see (1)in FIG. 12). The information sent is preferably authenticated, e.g. by akey derived from k and/or x in a similar way. The data is received bythe DRM application on the SIM, which, if an authentication tag ispresent, first authenticates the received data, and then runs the samefunctions f and g to derive the session key, t and the response, RES,respectively. The response is sent back to the operator so that theoperator can verify that it is in contact with the right application.Subsequently, the application places an order (protected by the key t)on what media and what rights it wishes to gain to the operator. Theorder is typically generated by a browser application in the device.Note that the browser application is in this case also a trusted andauthenticated application, or the user must be given the possibility toconfirm the placed order. The operator returns a session key s, alongwith a ticket describing the ordered media and rights. This session keyis to be later used for the actual media protection. The ticket and thesession key s are sent in duplicates. One is protected by the key c(known only to the content provider and the operator), the other isprotected by the key t (known only to the client and the operator). Theclient decrypts the ticket and the key s and checks that the ticketcorresponds to the earlier placed order.

The key s can now be output to another application 130 (FIG. 12) in theclient device (not necessarily on the SIM itself), or, to a completelystand-alone external device 130 in the overall client system, that usingthe key s later decrypts the received media and renders it to the user.Note that it may be the case that the actual rendering/decryption isdone in another tamper-resistant module, distinct from the SIM. If so,as mentioned above, it might be advisable to establish device-key basedcommunication between that device and the SIM DRM application so that scan be sent encrypted between the SIM and that device (see (2) in FIG.12), using any of the above proposed solutions. This also, as discussedabove, enables the SIM application to authenticate that it is in contactwith a tamper resistant device having valid DRM functionality. The SIMcould either rely on implicit authentication (i.e. only a device knowingthe device key y/y′ can decrypt the session key s), or perform anexplicit authentication based on the key y/y′. If is desirable to “hide”the actual device key y, and instead derive a device key representationy′ to be used for encryption, decryption and/or authentication, thecommon challenge r has to be transferred from the trusted party to theSIM and also to the rendering device. If the rendering device 130 is“stand-alone” it is recommended that it has its own rule-enforcement andis given the usage rules, for example in the ticket along with themedia, so that it can act as an agent on behalf of the contentowner/provider and assert that the usage rules are followed. The ruleenforcement could alternatively be implemented in the SIM, ordistributed between the SIM and the rendering device.

The client next sends the ticket and session key s (still protected bythe key c) to the content provider (see (3) in FIG. 12). The contentprovider removes the protection from the ticket and extracts the key s.If this is successful, the content provider knows that the ticketoriginated from an operator with whom he has an agreement. If any set-upmessages are needed between the client and the content provider prior tosending the media, this traffic is protected by the key s (or some otherkey derived from s). Finally, the content provider encrypts the media bythe session key s, and sends (downloads or streams) it to the renderingdevice (see (4) in FIG. 12).

It is also possible to let the rendering device authenticate that themedia protection key s really comes from a SIM that has been paired withthe rendering device through the device key information, y and/or y′.

The ticket-based protocol above is of course not the only possible; manyvariations exist as can easily be seen by those of ordinary skill in theart.

The invention also fits into current version of the emerging OMAstandard (previously known as WAP/WAP-DRM standard). The WirelessApplication Protocol (WAP) is standardized by OMA/WAP-Forum. There iscurrently ongoing work to come up with a way to enforce DRM in the scopeof WAP [10, 11]. At present, the standardization work is mainly targetedat download.

The WAP solution separates the media download of a DRM object in twoparts: the media object and the rights object. The download can beperformed using one of three defined methods:

-   -   Forward-lock: The client downloads only the media object. The        media object has some simple default rights, e.g. a “preview        object”, and can not be forwarded to another user.    -   Combined download: The client downloads both the media object        and the rights object.    -   Separate delivery: The client downloads the media object, which        is encrypted with a key CEK (Content Encryption Key). The rights        object and CEK can later (or simultaneously) be pushed to the        client.

The client is assumed to be an authorized entity, i.e. the device inwhich it resides can trust that the client behaves in a good way, andobeys any rights imposed by a rights object. No non-authorized entity,e.g. a text-editor or a game that is installed in the device has accessto the DRM objects in unencrypted form (possibly not even in encryptedform).

The WAP DRM client defined in [10, 11] may be implemented as anapplication in an application environment of a tamper-resistant identitymodule as described above. The WAP-DRM standard, however, assumes thatthe media rendering device and the download client both resides in thesame physical entity. This limitation can be relaxed without violatingthe WAP-DRM standard by configuring the rending device and the identitymodule's DRM application by a shared secret key, y, (or properlyconfigured asymmetric key pair) so that the CEK key can be sent inprotected form between the identity module and the rendering device.

The Forward-lock and Combined download models specify that the media andrights are downloaded to the DRM client. According to the invention, therights object may be included in the ticket, and the media object may bedownloaded to the rendering device. Note that in this respect there isno real difference between download and streaming. In references [10,11] that are mainly targeted at download, there is a suggestion toperform streaming by downloading an SDP description of the stream in themedia object, and then use that description to set up the streamingsession. It poses no problems at all to fit that into the solutionproposed by the invention, the SDP description is simply passed insidethe ticket. For information on SDP, reference is made to [12].Preferably, the DRM client implemented in the application environment ofthe SIM also includes functionality for checking that the forward-lockfunction of the WAP Protocol is not violated.

The Separate delivery model specifies a way to first download the mediaobject, and then separately download, or rather push, the rights objectto the client. The invention can be used also in the implementation ofthis model. The media object is protected by a Content Encryption Key(CEK). With the notation used in the protocol of the invention, themedia protection key s is an instantiation of the CEK. The inventionalso provides a way to authenticate the download client to the deviceand vice versa, e.g. based on the key x and/or y(y′). Thisauthentication is left as “out of scope” in [10, 11].

The embodiments described above are merely given as examples, and itshould be understood that the present invention is not limited thereto.Further modifications, changes and improvements that retain the basicunderlying principles disclosed and claimed herein are within the scopeand spirit of the invention.

REFERENCES

-   [1] A. J. Menezes, P. C. van Oorschot and S. C. Vanstone, “Handbook    of Applied Cryptography”, Chapters 1, 10 and 11, CRC Press.-   [2] L. Kaati, “Cryptographic Techniques and Encodings for Digital    Rights Management”, Master's Thesis in Computer Science, Department    of Numerical Analysis and Computer Science, Royal Institute of    Technology, Stockholm University, 2001.-   [3] Swedish Patent Application No. 0101295-4 filed Apr. 10, 2001.-   [4] “Specification of the SIM Application Toolkit for the Subscriber    Identity Module—Mobile Equipment (SIM—ME) interface”, 3GGP TS 11.14,    ETSI TS 101 267, Technical Specification 3^(rd) Generation    Partnership Project, Technical Specification Group Terminals,    Version 8.10.0, 1999.-   [5] “USIM Application Toolkit (USAT)”, 3GGP TS 31.111, ETSI TS 131    111, Technical Specification 3^(rd) Generation Partnership Project,    Technical Specification Group Terminals, Version 4.4.0, Release 4.-   [6] “Specification of the Subscriber Identity Module—Mobile    Equipment (SIM—ME) interface” 3GPP TS 11.11, ETSI TS 100 977,    Technical Specification 3^(rd) Generation Partnership Project,    Technical Specification Group Terminals, Version 8.5.0, 1999.-   [7] “GSM API for SIM Toolkit, Stage 2”, 3GGP TS 03.19, ETSI TS 101    476, Technical Specification 3^(rd) Generation Partnership Project,    Technical Specification Group Terminals, Version 8.4.0, 1999.-   [8] “Security Mechanism for SIM Application Toolkit, Stage 2”, 3GGP    TS 03.48, ETSI TS 101 181, Technical Specification 3^(rd) Generation    Partnership Project, Technical Specification Group Terminals,    Version 8.8.0, 1999.-   [9] “Subscriber Identity Modules (SIM), Functional Characteristics”,    ETSI TS 100 922, GSM 02.17, Technical Specification Digital Cellular    Telecommunications system, Version 3.2.0, February 1992.-   [10] “Download Architecture Version 1.0”, Proposed version    10-Jun.-2002, Open Mobile Alliance.-   [11] “Digital Rights Management Version 1.0”, Proposed version    28-Jun.-2002, Open Mobile Alliance.-   [12] M. Handley, V. Jacobson, “SDP: Session Description Protocol”,    RFC 2327, April 1998.

1. A tamper-resistant identity module adapted for physical engagement with a client system having means for receiving digital content over a network and a digital-content usage device, wherein said tamper-resistant identity module comprises a digital rights management (DRM) agent for enabling usage of said digital content.
 2. The tamper-resistant identity module according to claim 1, wherein said DRM agent is implemented as an application in an application environment of said tamper-resistant identity module.
 3. The tamper-resistant identity module according to claim 2, wherein said DRM agent application is loaded into said identity module application environment from an external trusted party associated with said identity module.
 4. The tamper-resistant identity module according to claim 3, wherein said identity module comprises means for authenticating said DRM agent.
 5. The tamper-resistant identity module according to claim 1, further comprising means for performing at least part of an authentication and key agreement (AKA) procedure, and said DRM agent includes means for performing DRM processing based on information from said AKA procedure.
 6. The tamper-resistant identity module according to claim 5, wherein said DRM agent includes means for extracting a content-protection key to be used for decrypting encrypted digital content provided from a content provider, based on information from said AKA procedure.
 7. The tamper-resistant identity module according to claim 1, wherein said DRM agent comprises means for enabling charging for digital content usage.
 8. The tamper-resistant identity module according to claim 1, wherein said DRM agent comprises means for managing information related to usage of said digital content, said usage information serving as a basis for charging for digital-content usage.
 9. The tamper-resistant identity module according to claim 8, wherein said DRM agent further comprises: means for integrity protecting said usage information based on an identity-module specific key; and means for sending said integrity protected usage information to an external party managing charging of digital-content usage.
 10. The tamper-resistant identity module according to claim 1, wherein said DRM agent implemented in said identity module further comprises means for enabling registration of at least one digital-content usage device.
 11. The tamper-resistant identity module according to claim 1, further comprising means for communication between said DRM agent and further DRM functionality implemented in said digital-content usage device based on usage-device specific key information.
 12. The tamper-resistant identity module according to claim 11, wherein said communication means is operable for ensuring that only a usage device with valid DRM functionality is enabled to use said digital content.
 13. The tamper-resistant identity module according to claim 1, wherein said DRM agent comprises means for receiving, from an external trusted party, a DRM application adapted for use with a digital-content usage device, and means for transferring said DRM application into a tamper-resistant application environment in said digital-content usage device based on usage-device specific key information.
 14. The tamper-resistant identity module according to claim 1, wherein said DRM agent implemented in said identity module includes means for checking that the forward-lock function of the Wireless Application Protocol (WAP) is not violated.
 15. A client system comprising: means for receiving digital content over a network; a digital-content usage device; a tamper-resistant identity module implemented with a digital rights management (DRM) agent for enabling usage of said digital content by said digital-content usage device.
 16. The client system according to claim 15, wherein said DRM agent is implemented as an application in an application environment of said tamper-resistant identity module.
 17. The client system according to claim 16, wherein said DRM agent application is loaded into said identity module application environment from an external trusted party associated with said identity module.
 18. The client system according to claim 17, wherein said identity module comprises means for authenticating said DRM agent.
 19. The client system according to claim 15, wherein said identity module further comprises means for performing at least part of an authentication and key agreement (AKA) procedure, and said DRM agent includes means for performing DRM processing based on information from said AKA procedure.
 20. The client system according to claim 19, wherein said DRM agent includes means for extracting a content-protection key to be used for decrypting encrypted digital content provided from a content provider, based on information from said AKA procedure.
 21. The client system according to claim 19, wherein said DRM agent comprises means for enabling charging for digital content usage.
 22. The client system according to claim 15, further comprising means for communication between said DRM agent and a further DRM agent implemented in said digital-content usage device based on usage-device specific key information.
 23. The client system according to claim 22, wherein said communication means is operable for ensuring that only a usage device with valid DRM functionality is enabled to use said digital content.
 24. The client system according to claim 23, wherein said client system further comprises means for transmitting, to a trusted certification party, identification information associated with said digital-content usage device, and in response thereto receiving a protected representation of said usage-device specific key, and said DRM agent comprises means for extracting said usage-device specific key representation for storage in said tamper-resistant identity module.
 25. The client system according to claim 15, wherein said digital-content usage device includes a tamper-resistant application environment, and a DRM application adapted for use as a DRM agent in said usage device is loaded into said application environment at least partly based on usage-device specific key information.
 26. The client system according to claim 25, wherein said digital-content usage device comprises: means for generating new device key information associated with a downloaded DRM application at least partly based on said usage-device specific key information; and means for replacing usage-device specific key information stored in said usage device with said new device key information.
 27. The client system according to claim 26, wherein said DRM agent implemented in said identity module comprises means for replacing usage-device specific key information stored in said identity module with key information corresponding to said new device key information.
 28. A digital rights management (DRM) module comprising: a first DRM agent implemented in a tamper-resistant identity module for engagement with a client device, said first DRM agent comprising means for performing first DRM processing associated with digital content; a second DRM agent implemented in a digital-content usage device adapted for using said digital content, said second DRM agent comprising means for performing second DRM processing associated with said digital content; and means for communication between said first DRM agent and said second DRM agent based on usage-device specific key information.
 29. The DRM module according to claim 28, wherein said communication means is operable for ensuring that only a usage device with valid DRM functionality is enabled to use said digital content.
 30. The DRM module according to claim 28, wherein said tamper-resistant identity module comprises means for performing at least part of an authentication and key agreement (AKA) procedure, and said means for performing first DRM processing in said first DRM agent operates based on information from said AKA procedure.
 31. The DRM module according to claim 30, wherein said means for performing first DRM processing in said first DRM agent includes means for extracting a content-protection key to be used for decrypting protected digital content from a content provider, based on information from said AKA procedure.
 32. The DRM module according to claim 31, wherein said communication means is operable for ensuring that said content-protection key is accessible only by a second DRM agent that properly enforces usage rules associated with said digital content.
 33. The DRM module according to claim 32, wherein said means for performing second DRM processing in said second DRM agent comprises means for decrypting encrypted digital content by means of said content-protection key.
 34. The DRM module according to claim 30, wherein said means for performing first DRM processing in said first DRM agent comprises means for enabling charging for said digital content.
 35. The DRM module according to claim 28, wherein said first DRM agent comprises: means for authenticating said usage device based on said usage-device specific key information to verify that said usage device has valid DRM functionality; and means for sending DRM data enabling usage of said digital content to said second DRM agent in response to successful authentication of a usage device with valid DRM functionality.
 36. The DRM module according to claim 28, wherein said first DRM agent comprises: means for encrypting DRM data enabling usage of said digital content, based on said usage-device specific key information; and means, forming part of said communication means, for sending said encrypted DRM data to said second DRM agent; and said second DRM agent comprises means for decrypting said encrypted DRM data to enable usage of said digital content, based on said usage-device specific key information.
 37. The DRM module according to claim 28, wherein said tamper-resistant identity module and said usage device are tamper-resistantly configured with usage-device specific key information.
 38. The DRM module according to claim 28, wherein said second DRM agent comprises means for compiling information related to usage of said digital content, and means for transferring said usage information to said first DRM agent based on said usage-device specific key information; and said first DRM agent comprises means for sending said usage information to an external party managing charging of digital-content usage, said usage information serving as a basis for charging for digital-content usage.
 39. The DRM module according to claim 28, wherein said second DRM agent comprises means for sending a first control signal related to the digital-content usage process to said first DRM agent, and said first DRM agent comprises means for processing signal data associated with said first control signal to generate a second control signal, and means for sending said second control signal to said second DRM agent for controlling said digital-content usage process.
 40. The DRM module according to claim 28, wherein said first DRM agent is implemented as an application in an application environment of said tamper-resistant identity module.
 41. The DRM module according to claim 40, wherein said first DRM agent application is loaded into said identity module application environment from an external trusted party associated with said identity module.
 42. The DRM module according to claim 40, wherein said identity module comprises means for authenticating said DRM agent.
 43. The DRM module according to claim 28, wherein said second DRM agent is implemented as an application in a tamper-resistant application environment in said usage device.
 44. The DRM module according to claim 43, wherein said second DRM agent application is loaded into said usage-device application environment at least partly based on said usage-device specific key information.
 45. The DRM module according to claim 44, wherein said digital-content usage device comprises: means for generating new device key information associated with said downloaded DRM application at least partly based on said usage-device specific key information; and means for replacing usage-device specific key information stored in said usage device with said new device key information.
 46. The DRM module according to claim 45, wherein said DRM agent implemented in said identity module comprises means for replacing usage-device specific key information stored in said identity module with key information corresponding to said new device key information.
 47. A method for digital rights management (DRM) comprising the steps of: tamper-resistantly configuring a usage device, adapted for using digital content, with a usage-device specific key; providing a cryptographic representation of said usage-device specific key to a client device associated with said usage device; processing, at a trusted certification party, said cryptographic representation received in a request from said client device to retrieve key information representative of said usage-device specific key; securely transferring said key information from said trusted certification party to a tamper-resistant identity module in said client device, based on an identity-module specific key; and establishing communication between a first DRM agent in said tamper-resistant identity module and a second DRM agent in said usage device based on the key information transferred to the identity module and the usage-device specific key in said usage device. 